home *** CD-ROM | disk | FTP | other *** search
Text File | 1997-08-06 | 62.4 KB | 1,628 lines |
-
-
-
-
-
-
- Network Working Group E. Huizer
- Request for Comments: 1603 SURFnet bv
- Category: Informational D. Crocker
- Silicon Graphics, Inc.
- March 1994
-
-
- IETF Working Group
- Guidelines and Procedures
-
- Status of this Memo
-
- This memo provides information for the Internet community. This memo
- does not specify an Internet standard of any kind. Distribution of
- this memo is unlimited.
-
- Abstract
-
- The Internet Engineering Task Force (IETF) has responsibility for
- developing and reviewing specifications intended as Internet
- Standards. IETF activities are organized into working groups (WGs).
- This document describes the guidelines and procedures for formation
- and operation of IETF working groups. It describes the formal
- relationship between IETF participants WG and the Internet
- Engineering Steering Group (IESG). The basic duties of IETF
- participants, including WG Chair and IESG Area Directors are defined.
-
- Table of Contents
-
- 1. INTRODUCTION.............................................. 2
- 1.1. IETF approach to standardization........................ 3
- 1.2. Acknowledgments......................................... 4
- 2. WORKING GROUP (WG) FORMATION.............................. 5
- 2.1. Criteria for formation.................................. 5
- 2.2. Charter................................................. 6
- 2.3. Charter review & approval............................... 9
- 2.4. Birds of a feather (BOF)................................ 9
- 3. WORKING GROUP OPERATION................................... 11
- 3.1. Session planning........................................ 11
- 3.2. Session venue........................................... 12
- 3.3. Session management...................................... 14
- 3.4. Contention and appeals overview......................... 15
- 4. WORKING GROUP TERMINATION................................. 16
- 5. STAFF ROLES............................................... 17
- 5.1. WG Chair................................................ 17
- 5.2. WG Editor/Secretary..................................... 19
- 5.3. WG Facilitator.......................................... 19
- 5.4. Design teams............................................ 19
-
-
-
- Huizer & Crocker [Page 1]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
- 5.5. Area Consultant......................................... 19
- 5.6. Area Director........................................... 20
- 5.7. Area Directorate........................................ 21
- 6. WORKING GROUP DOCUMENTS................................... 21
- 6.1. Session documents....................................... 21
- 6.2. IETF meeting document archive........................... 21
- 6.3. Internet-Drafts (I-D)................................... 23
- 6.4. Request For Comments (RFC).............................. 24
- 6.5. Submission of documents................................. 24
- 6.6. Review of documents..................................... 25
- 7. SECURITY CONSIDERATIONS................................... 26
- 8. REFERENCES................................................ 26
- 9. AUTHORS' ADDRESSES........................................ 27
- APPENDIX: SAMPLE WORKING GROUP CHARTER........................ 28
-
- 1. INTRODUCTION
-
- This document defines guidelines and procedures for Internet
- Engineering Task Force working groups. The Internet is a loosely-
- organized international collaboration of autonomous, interconnected
- networks; it supports host-to-host communication through voluntary
- adherence to open protocols and procedures defined by Internet
- Standards, a collection of which are commonly known as "the TCP/IP
- protocol suite". The Internet Standards Process is defined in [1].
- Development and review of potential Internet Standards from all
- sources is conducted by the Internet Engineering Task Force (IETF).
-
- The IETF is a large, open community of network designers, operators,
- vendors, users, and researchers concerned with the Internet and the
- technology used on it. The IETF is managed by its Internet
- Engineering Steering Group (IESG) whose membership includes an IETF
- Chair, responsible for oversight of general IETF operations, and Area
- Directors, each of whom is responsible for a set of IETF activities
- and working groups. The IETF Executive Director and IESG Secretary
- are ex-officio participants, as are the IAB Chair and a designated
- Internet Architecture Board (IAB) member. At present there are 10
- areas, though the number and purview of areas changes over time:
-
- User Services (USV)
- Applications (APP)
- Service Applications (SAP)
- Transport Services (TSV)
- Internet (INT)
- Routing (RTG)
- Network Management (MGT)
- Operational Requirements (OPS)
- Security (SEC)
- Standards & Processes (STD)
-
-
-
- Huizer & Crocker [Page 2]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
- Most areas have an advisory group or directorate. The specific name
- and the details of the role for each group differs from area to area,
- but the primary intent is that the group assist the Area Director,
- e.g., with the review of specifications produced in the area. An
- advisory group is formed by an Area Director (AD) and comprises
- experienced members of the IETF and technical community represented
- by the area. A small IETF Secretariat provides staff and
- administrative support for the operation of the IETF.
-
- The primary activities of the IETF are performed by committees known
- as working groups. There are currently more than 60 of these.
- Working groups tend to have a narrow focus and a lifetime bounded by
- completion of a specific task, although there are exceptions.
-
- There is no formal membership in the IETF. Participation is open to
- all. This participation may be by on-line contribution, attendance
- at face-to-face sessions, or both. Anyone from the Internet
- community who has the time and interest is urged to participate in
- IETF meetings and any of its on-line working group discussions.
- Participation is by individual technical contributors, rather than by
- formal representatives of organizations.
-
- This document defines procedures and guidelines for formation and
- operation of working groups in the IETF. It defines the relations of
- working groups to other bodies within the IETF. The duties of working
- group Chairs and Area Directors with respect to the operation of the
- working group are also defined. The document uses: "shall", "will",
- "must" and "is required" where it describes steps in the process that
- are essential, and uses: "suggested", "should" and "may" are where
- guidelines are described that are not essential, but are strongly
- recommended to help smooth WG operation.
-
- 1.1. IETF approach to standardization
-
- The reader is encouraged to study The Internet Standards Process [1].
- Familiarity with this document is essential for a complete
- understanding of the philosophy, procedures and guidelines described
- in this document.
-
- The goals of the process are summarized in [1]:
-
- "In general, an Internet Standard is a specification that is
- stable and well-understood, is technically competent, has
- multiple, independent, and interoperable implementations
- with operational experience, enjoys significant public
- support, and is recognizably useful in some or all parts of
- the Internet.
- ...
-
-
-
- Huizer & Crocker [Page 3]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
- "In outline, the process of creating an Internet Standard is
- straightforward: a specification undergoes a period of
- development and several iterations of review by the Internet
- community and perhaps revision based upon experience, is
- adopted as a Standard by the appropriate body (see below),
- and is published.
-
- "In practice, the process is somewhat more complicated, due
- to (1) the number and type of possible sources for
- specifications; (2) the need to prepare and revise a
- specification in a manner that preserves the interests of
- all of the affected parties; (3) the importance of
- establishing widespread community agreement on its technical
- content; and (4) the difficulty of evaluating the utility of
- a particular specification for the Internet community.
- ...
- "These procedures are explicitly aimed at developing and
- adopting generally-accepted practices. Thus, a candidate
- for Internet standardization is implemented and tested for
- correct operation and interoperability by multiple,
- independent parties, and utilized in increasingly demanding
- environments, before it can be adopted as an Internet
- Standard."
-
- The IETF standardization process has been marked by informality. As
- the community of participation has grown it has become necessary to
- document procedures, while continuing to avoid unnecessary
- bureaucracy. This goals of this balancing act are summarized in [1]
- as:
-
- "The procedures that are described here provide a great deal
- of flexibility to adapt to the wide variety of circumstances
- that occur in the Internet standardization process.
- Experience has shown this flexibility to be vital in
- achieving the following goals for Internet standardization:
-
- * high quality,
- * prior implementation and testing,
- * openness and fairness, and
- * timeliness."
-
- 1.2. Acknowledgments
-
- Much of this document is due to the copy-and-paste function of a word
- processor. Several passages have been taken from the documents cited
- in the reference section. The POISED WG provided discussion and
- comments. Three people deserve special mention, as especially large
- chunks of their documents have been integrated into this one: Vint
-
-
-
- Huizer & Crocker [Page 4]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
- Cerf [7] from whom we borrowed the description of the IETF; and Greg
- Vaudreuil and Steve Coya who provided several paragraphs. Also, John
- Stewart and Steve Crocker did a truly stellar job of proof-reading.
- However, all the errors you'll find are probably ours.
-
- 2. WORKING GROUP (WG) FORMATION
-
- IETF working groups (WGs) are the primary mechanism for development
- of IETF specifications and guidelines, many of which are intended as
- standards or recommendations. A working group may be established at
- the initiative of an Area Director (AD) or it may be initiated by an
- individual or group of individuals. Anyone interested in creating an
- IETF working group must obtain the advice and consent of the
- appropriate IETF Area Director under whose direction the working
- group would fall and must proceed through the formal steps detailed
- in this section.
-
- A working group is typically created to address a specific problem or
- produce a deliverable (a guideline, standards specification, etc.)
- and is expected to be short-lived in nature. Upon completion of its
- goals and achievement of its objectives, the working group as a unit
- is terminated. Alternatively at the discretion of the IESG, Area
- Director, the WG Chair and the WG participants, the objectives or
- assignment of the working group may be extended by enhancing or
- modifying the working group's charter.
-
- 2.1. Criteria for formation
-
- When determining whether it is appropriate to create a working group,
- the Area Director and the IESG will consider several issues:
-
- - Are the issues that the working group plans to address clear
- and relevant for the Internet community?
-
- - Are the goals specific and reasonably achievable, and
- achievable within the time frame specified by the
- milestones?
-
- - What are the risks and urgency of the work, to determine the
- level of attention required?
-
- - Do the working group's activities overlap with those of
- another working group? If so, it may still be appropriate to
- create the working group, but this question must be
- considered carefully by the Area Directors as subdividing
- efforts often dilutes the available technical expertise.
-
-
-
-
-
- Huizer & Crocker [Page 5]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
- - Is there sufficient interest and expertise in the working
- group's topic with at least several people willing to expend
- the effort to produce the desired result (e.g., a protocol
- specification)? Working groups require considerable effort,
- including management of the working group process, editing
- of working group documents, and contribution to the document
- text. IETF experience suggests that these roles typically
- cannot all be handled by one person; four or five active
- participants are typically required.
-
- - Does a base of interested consumers (end users) appear to
- exist for the planned work? Consumer interest can be
- measured by participation of end-users within the IETF
- process, as well as by less direct means.
-
- Considering the above criteria, the Area Director will decide whether
- to pursue the formation of the group through the chartering process.
-
- 2.2. Charter
-
- The formation of a working group requires a charter which is
- primarily negotiated between a prospective working group Chair and
- the relevant Area Director, although final approval is made by the
- IESG and all charters are reviewed by the Internet Architecture Board
- (IAB). A charter is a contract between a working group and the IETF
- to perform a set of tasks. A charter:
-
- 1. Lists relevant administrative aspects of the working group;
-
- 2. Specifies the direction or objectives of the working group
- and describes the approach that will be taken to achieve the
- goals; and
-
- 3. Enumerates a set of milestones together with time frames for
- their completion.
-
- When the prospective Chair, the Area Director and the IESG Secretary
- are satisfied with the charter form and content, it becomes the basis
- for forming a working group. The AD may require an initial draft of a
- charter to be available prior to holding an exploratory Birds of a
- Feather (BOF) meeting, as described below.
-
- Charters may be renegotiated periodically to reflect the current
- status, organization or goals of the working group. Hence, a charter
- is a contract between the IETF and the working group which is
- committing to meet explicit milestones and delivering concrete
- "products".
-
-
-
-
- Huizer & Crocker [Page 6]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
- Specifically, each charter consists of 6 sections:
-
- Working group name
-
- A working group name should be reasonably descriptive or
- identifiable. Additionally, the group shall define an
- acronym (maximum 8 printable ASCII characters) to reference
- the group in the IETF directories, mailing lists, and
- general documents.
-
- Chair(s)
-
- The working group may have one or two Chair(s) to perform
- the administrative functions of the group. The email
- address(es) of the Chair(s) shall be included.
-
- Area and Area Director(s)
-
- The name of the IETF area with which the working group is
- affiliated and the name and electronic mail address of the
- associated Area Director.
-
- Mailing list
-
- It is required that an IETF working group have a general
- Internet mailing list. Most of the work of an IETF working
- group will be conducted that.
-
- The charter shall include:
-
- The address to which a participant sends a
- subscription request and the procedures to follow when
- subscribing,
-
- The address to which a participant sends submissions
- and special procedures, if any, and
-
- The location of the mailing list archive, if any.
-
- A message archive should be maintained in a public place
- which can be accessed via FTP. The ability to retrieve from
- the archive via electronic mail requests also is
- recommended. Additionally, the address:
-
- ietf-archive@cnri.reston.va.us
-
- shall be included on the mailing list.
-
-
-
-
- Huizer & Crocker [Page 7]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
- NOTE: It is strongly suggested that the mailing list be on
- a host directly connected to the IP Internet to facilitate
- use of the SMTP expansion command (EXPN) and to allow mail
- archive access via FTP, gopher and the like in keeping with
- the general IETF rule for openness. If this is not possible,
- the message archive and membership of the list must be made
- available to those who request it by sending a message to
- the list-request alias.
-
- Description of working group
-
- The focus and intent of the group shall be set forth briefly. By
- reading this section alone, an individual should be able to decide
- whether this group is relevant to their own work. The first paragraph
- must give a brief summary of the problem area, basis, goal(s) and
- approach(es) planned for the working group. This paragraph will
- frequently be used as an overview of the working group's effort.
-
- The terms "they", "them" and "their" are used in this document as
- third-person singular pronouns.
-
- To facilitate evaluation of the intended work and to provide
- on-going guidance to the working group, the charter shall
- describe the problem being solved and shall discuss
- objectives and expected impact with respect to:
-
- - Architecture
- - Operations
- - Security
- - Network management
- - Transition (where applicable)
-
- Goals and milestones
-
- The working group charter must establish a timetable for
- work. While this may be re-negotiated over time, the list
- of milestones and dates facilitates the Area Director's
- tracking of working group progress and status, and it is
- indispensable to potential participants identifying the
- critical moments for input. Milestones shall consist of
- deliverables that can be qualified as showing specific
- achievement; e.g., "Internet-Draft finished" is fine, but
- "discuss via email" is not. It is helpful to specify
- milestones for every 3-6 months, so that progress can be
- gauged easily. This milestone list is expected to be
- updated periodically. Updated milestones are re-negotiated
- with the Area Director and the IESG, as needed, and then are
- submitted to the IESG Secretary:
-
-
-
- Huizer & Crocker [Page 8]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
-
- IESG-secretary@cnri.reston.va.us
-
- An example of a WG charter is in Appendix A.
-
- 2.3. Charter review & approval
-
- Working groups often comprise technically competent participants who
- are not familiar with the history of Internet architecture or IETF
- processes. This can, unfortunately, lead to good working group
- consensus about a bad design. To facilitate working group efforts,
- an Area Director may assign an Area Consultant from among the ranks
- of senior IETF participants. (Area Consultants are described in the
- section of Staff Roles.) At the discretion of the AD, approval of a
- new WG may be withheld in the absence of sufficient Consultant
- resources.
-
- Once the Area Director (and the Area Directorate, as the AD deems
- appropriate) has approved the working group charter, the charter is
- submitted for review by the IAB and approval by the Internet
- Engineering Steering Group using the criteria described previously.
-
- The Internet Architecture Board (IAB) will review the charter of the
- proposed WG to determine the relationship of the proposed work to the
- overall architecture of the Internet Protocol Suite.
-
- The approved charter is submitted to the IESG Secretary who records
- and enters the information into the IETF tracking database and
- returns the charter in a form formatted by the database. The working
- group is announced to the IETF mailing list by the IESG Secretary.
-
- 2.4. Birds of a feather (BOF)
-
- Often it is not clear whether an issue merits the formation of a
- working group. To facilitate exploration of the issues the IETF
- offers the possibility of a Birds of a Feather (BOF) session, as well
- as the early formation of an email list for preliminary discussion.
- Alternatively, a BOF may serve as a forum for a single presentation
- or discussion, without any intent to form a working group.
-
- A BOF is a session at an IETF meeting which permits "market research"
- and technical "brainstorming". Any individual may request permission
- to hold a BOF on a subject. The request must be filed with the
- relevant Area Director. The person who requests the BOF is usually
- appointed as Chair of the BOF. The Chair of the BOF is also
- responsible for providing a report on the outcome of the BOF.
-
-
-
-
-
- Huizer & Crocker [Page 9]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
- The AD may require the conduct of email discussion, prior to
- authorizing a BOF. This permits initial exchanges and sharing of
- framework, vocabulary and approaches, in order to make the time spent
- in the BOF more productive. The AD may require that a BOF be held,
- prior to establishing a working group, and the AD may require that
- there be a draft of the WG charter prior to holding a BOF.
-
- Usually the outcome of a BOF will be one of the following:
-
- - There was enough interest and focus in the subject to
- warrant the formation of a WG;
-
- - The discussion came to a fruitful conclusion, with results
- to be written down and published, however there is no need
- to establish a WG; or
-
- - There was not enough interest in the subject to warrant the
- formation of a WG.
-
- There is an increasing demand for BOF sessions at IETF meetings.
- Therefore the following rules apply for BOFs:
-
- - All BOFs must have the approval of the appropriate Area
- Director. The Secretariat will NOT schedule or allocate time
- slots without the explicit approval of the Area Director.
-
- - The purpose of a BOF is to conduct a single, brief
- discussion or to ascertain interest and establish goals for
- a working group. All BOF organizers are required to submit a
- brief written report of what transpired during the BOF
- session together with a roster of attendees to the IESG
- Secretary for inclusion in the Proceedings.
-
- - A BOF may be held only once (ONE slot at one IETF Plenary
- meeting).
-
- - Under unusual circumstances an Area Director may, at their
- discretion, allow a BOF to meet for a second time. Typically
- (though not a requirement) this is to develop a charter to
- be submitted to the IESG.
-
- - BOFs are not permitted to meet three times.
-
-
-
-
-
-
-
-
-
- Huizer & Crocker [Page 10]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
- - A BOF may be held for single-event discussion, or may pursue
- creation of normal IETF working groups for on-going
- interactions and discussions. When the request for a BOF
- comes from a formally-constituted group, rather than from an
- individual, the rules governing the handling of the request
- are the same as for all other BOFs and working groups.
-
- - When necessary, WGs will be given priority for meeting space
- over BOFs.
-
- 3. WORKING GROUP OPERATION
-
- The IETF has basic requirements for open and fair participation and
- for thorough consideration of technical alternatives. Within those
- constraints, working groups are autonomous and each determines most
- of the details of its own operation with respect to session
- participation, reaching closure, etc. The core rule for operation is
- that acceptance or agreement is achieved via working group "rough
- consensus".
-
- A number of procedural questions and issues will arise over time, and
- it is the function of the Working Group Chair to manage the group
- process, keeping in mind that the overall purpose of the group is to
- make progress towards reaching rough consensus in realizing the
- working group's goals and objectives.
-
- There are few hard and fast rules on organizing or conducting working
- group activities, but a set of guidelines and practices have evolved
- over time that have proven successful. These are listed here, with
- actual choices typically determined by the working group participants
- and the Chair.
-
- 3.1. Session planning
-
- For coordinated, structured WG interactions, the Chair must publish a
- draft agenda well in advance of the actual session. The agenda needs
- to contain at least:
-
- - The items for discussion;
-
- - The estimated time necessary per item; and
-
- - A clear indication of what documents the participants will
- need to read before the session in order to be well
- prepared.
-
-
-
-
-
-
- Huizer & Crocker [Page 11]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
- Publication shall include sending a copy to the working group mailing
- list and to the IETF-Announce list. Notices for the IETF-Announce
- list should be sent to:
-
- ietf-announce-post@cnri.reston.va.us
-
- All working group actions shall be taken in a public forum, and wide
- participation is encouraged. A working group will conduct much of
- its business via electronic mail distribution lists but may meet
- periodically to discuss and review task status and progress, to
- resolve specific issues and to direct future activities. It is
- common, but not required, that a working group will meet at the
- trimester IETF Plenary events. Additionally, interim sessions may be
- scheduled for telephone conference, video teleconference, or for
- face-to-face (physical) sessions.
-
- All working group sessions (including those held outside of the IETF
- meetings) shall be reported by making minutes available. These
- minutes should include the agenda for the session, an account of the
- discussion including any decisions made, and a list of attendees. The
- Working Group Chair is responsible for insuring that session minutes
- are written and distributed, though the actual task may be performed
- by someone designated by the Working Group Chair. The minutes shall
- be submitted in printable ASCII text for publication in the IETF
- Proceedings, and for posting in the IETF Directories and are to be
- sent to:
-
- minutes@cnri.reston.va.us
-
- 3.2. Session venue
-
- Each working group will determine the balance of email and face-to-
- face sessions that is appropriate for achieving its milestones.
- Electronic mail permits the widest participation; face-to-face
- meetings often permit better focus and therefore can be more
- efficient for reaching a consensus among a core of the working group
- participants. In determining the balance, the WG must ensure that
- its process does not serve to exclude contribution by email-only
- participants. Also note that decisions reached during IETF meetings
- are NOT final, but must be conveyed to the mailing list to verify WG
- consensus.
-
- IETF Meetings
-
- If a WG needs a session at an IETF meeting, the Chair must apply for
- time-slots as soon as the first announcement of that IETF meeting is
- made by the IETF Secretariat to the WG-chairs list. Session time is
- a scarce resource at IETF meetings, so placing requests early will
-
-
-
- Huizer & Crocker [Page 12]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
- facilitate schedule coordination for WGs requiring the same set of
- experts.
-
- The application for a WG session at an IETF meeting shall be made to
- the IETF Secretariat. Alternatively some Area Directors may want to
- coordinate WG sessions in their area and request that time slots be
- coordinated through them. After receiving all requests for time
- slots by WGs in the area, the Area Director(s) form a draft session-
- agenda for their area, which is then sent to the WG chairs of the
- area. After approval it will be sent to the IETF Secretariat.
-
- An application must contain:
-
- - The amount of time requested;
-
- - The rough outline of the WG agenda that is expected to be
- covered;
-
- - The estimated number of people that will attend the WG
- session;
-
- - Related WGs that must not be scheduled for the same time
- slot(s); and
-
- - Individuals whose attendance is desired.
-
- The Secretariat allots time slots on the basis of the session-agenda
- made by the Area Director(s). If the proposed session- agenda for an
- area does not fit into the IETF meeting-agenda, the IETF Secretariat
- will adjust it to fit, after consulting the Area Director(s) and the
- relevant chairs. The Secretariat will then form a draft session-
- agenda and distribute it among the Working Group Chairs for final
- approval.
-
- NOTE: While open discussion and contribution is essential to working
- group success, the Chair is responsible for ensuring forward
- progress. When acceptable to the WG, the Chair may call for
- restricted participation (but not restricted attendance!) at IETF
- working group sessions for the purpose of achieving progress. The
- Working Group Chair then has the authority to refuse to grant the
- floor to any individual who is unprepared or otherwise covering
- inappropriate material.
-
- On-line
-
- It can be quite useful to conduct email exchanges in the same manner
- as a face-to-face session, with published schedule and agenda, as
- well as on-going summarization and consensus polling.
-
-
-
- Huizer & Crocker [Page 13]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
- Many working group participants hold that mailing list discussion is
- the best place to consider and resolve issues and make decisions.
- Choice of operational style is made by the working group itself. It
- is important to note, however, that Internet email discussion is
- possible for a much wider base of interested persons than is
- attendance at IETF meetings, due to the time and expense required to
- attend.
-
- 3.3. Session management
-
- Working groups make decisions through a "rough consensus" process.
- IETF consensus does not require that all participants agree although
- this is, of course, preferred. In general the dominant view of the
- working group shall prevail. (However, it must be noted that
- "dominance" is not to be determined on the basis of volume or
- persistence, but rather a more general sense of agreement.)
- Consensus can be determined by balloting, humming, or any other means
- on which the WG agrees (by rough consensus, of course).
-
- The challenge to managing working group sessions is to balance the
- need for open and fair consideration of the issues against the need
- to make forward progress. The working group, as a whole, has the
- final responsibility for striking this balance. The Chair has the
- responsibility for overseeing the process but may delegate direct
- process management to a formally-designated Facilitator.
-
- It is occasionally appropriate to revisit a topic, to re-evaluate
- alternatives or to improve the group's understanding of a relevant
- decision. However, unnecessary repeated discussions on issues can be
- avoided if the Chair makes sure that the main arguments in the
- discussion (and the outcome) are summarized and archived after a
- discussion has come to conclusion. It is also good practice to note
- important decisions/consensus reached by email in the minutes of the
- next 'live' session, and to summarize briefly the decision-making
- history in the final documents the WG produces.
-
- To facilitate making forward progress, a Working Group Chair may wish
- to direct a discussion to reject or defer the input from a member,
- based upon the following criteria:
-
- Old
-
- The input pertains to a topic that already has been resolved
- and is redundant with information previously available;
-
-
-
-
-
-
-
- Huizer & Crocker [Page 14]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
- Minor
-
- The input is new and pertains to a topic that has already
- been resolved, but it is felt to be of minor import to the
- existing decision;
-
- Timing
-
- The input pertains to a topic that the working group has not
- yet opened for discussion; or
-
- Scope
-
- The input is outside of the scope of the working group
- charter.
-
- 3.4. Contention and appeals overview
-
- In the course of group design processes, strife happens. Strife and
- contention are particularly likely when working groups comprise many
- constituencies. On the other hand differences in view are vital to
- the success of the IETF and healthy debate is encouraged. Sometimes
- debates degenerate into something akin to warfare. For these
- circumstances, the IETF has an extensive review and appeals process.
-
- Formal procedures for requesting review and conducting appeals are
- documented in The Internet Standards Process [1]. A brief summary is
- provided, here.
-
- In fact the IETF approach to reviews and appeals is quite simple:
- When an IETF participant feels that matters have not been conducted
- properly, they should state their concern to a member of IETF
- management. In other words, the process relies upon those who have
- concerns raising them. If the result is not satisfactory, there are
- several levels of appeal available, to ensure that review is possible
- by a number of people uninvolved in the matter in question.
-
- Reviews and appeals step through four levels, each in turn:
-
- WG Chair
-
- An appeal must begin with the management closest to the
- operation of the working group, even if the concern applies
- to their own handling of working group process.
-
-
-
-
-
-
-
- Huizer & Crocker [Page 15]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
- Area
-
- If discussion and review with the WG Chair do not produce a
- satisfactory result, the complainant may bring their concern
- to the cognizant Area Director.
-
- IESG
-
- If a concerned party is not satisfied with the results of
- the area-level review, then they may bring the matter to the
- IESG Chair and the Area Director for Standards & Processes.
- The IESG Chair and the Standards & Processes AD will bring
- the issue before the full IESG for an additional review and
- will report the resolution back to the parties.
-
- IAB
-
- The IAB provides a final opportunity to appeal the results
- of previous reviews. If a concerned party does not accept
- the outcome of the IESG review, then they may take their
- concern to the IAB, by contacting the IAB Chair.
-
- Concerns entail either a disagreement with technical decisions by the
- working group or with the process by which working group business has
- been conducted. Technical disagreements may be about specific
- details or about basic approach. When an issue pertains to
- preference, it should be resolved within the working group. When a
- matter pertains to the technical adequacy of a decision, review is
- encouraged whenever the perceived deficiency is noted. For matters
- having to do with preference, working group rough consensus will
- dominate.
-
- When a matter pertains to working group process, it is important that
- those with a concern be clear about the manner in which the process
- was not open or fair and that they be willing to discuss the issue
- openly and directly. In turn, the IETF management will make every
- effort to understand how the process was conducted, what deficiencies
- were present (if any) and how the matter should be corrected. The
- IETF functions on the good will and mutual respect of its
- participants; continued success requires continued attention to
- working group process.
-
- 4. WORKING GROUP TERMINATION
-
- Working groups are typically chartered to accomplish a specific task.
- After that task is complete, the group will be disbanded. However if
- a WG produces a Proposed or Draft Standard, the WG will become
- dormant rather than disband (i.e., the WG will no longer conduct
-
-
-
- Huizer & Crocker [Page 16]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
- formal activities, but the mailing list will remain available to
- review the work as it moves to Draft Standard and Standard status.)
-
- If, at some point, it becomes evident that a working group is unable
- to complete the work outlined in the charter, the group, in
- consultation with its Area Director can either:
-
- 1. Recharter to refocus on a smaller task,
-
- 2. Choose new Chair(s), or
-
- 3. Disband.
-
- If the working group disagrees with the Area Director's choice, it
- may appeal to the IESG.
-
- 5. STAFF ROLES
-
- Working groups require considerable care and feeding. In addition to
- general participation, successful working groups benefit from the
- efforts of participants filling specific functional roles.
-
- 5.1. WG Chair
-
- The Working Group Chair is concerned with making forward progress
- through a fair and open process, and has wide discretion in the
- conduct of WG business. The Chair must ensure that a number of tasks
- are performed, either directly or by others assigned to the tasks.
- This encompasses at the very least the following:
-
- Ensure WG process and content management
-
- The Chair has ultimate responsibility for ensuring that a
- working group achieves forward progress and meets its
- milestones. For some working groups, this can be
- accomplished by having the Chair perform all management-
- related activities. In other working groups -- particularly
- those with large or divisive participation -- it is helpful
- to allocate process and/or secretarial functions to other
- participants. Process management pertains strictly to the
- style of working group interaction and not to its content.
- It ensures fairness and detects redundancy. The secretarial
- function encompasses document editing. It is quite common
- for a working group to assign the task of specification
- Editor to one or two participants. Often, they also are
- part of the design team, described below.
-
-
-
-
-
- Huizer & Crocker [Page 17]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
- Moderate the WG email list
-
- The Chair should attempt to ensure that the discussions on
- this list are relevant and that they converge to consensus
- agreements. The Chair should make sure that discussions on
- the list are summarized and that the outcome is well
- documented (to avoid repetition). The Chair also may choose
- to schedule organized on-line "sessions" with agenda and
- deliverables. These are structured as true meetings,
- conducted over the course of several days (to allow
- participation across the Internet.) Participants are
- expected to allocate time to the meeting, usually in the
- range of 1-2 hours per day of the "meeting".
-
- Organize, prepare and chair face-to-face & on-line formal sessions
-
- The Chair should plan and announce sessions well in advance.
- (See section on Session Planning for exact procedures.)
-
- Communicate results of sessions
-
- The Chair and/or Secretary must ensure that minutes of a
- session are taken and that an attendance list is circulated.
- See the section on Session Documents for detailed
- procedures.
-
- Immediately after a session, the WG Chair must immediately
- provide the Area Director with a very short report
- (approximately one paragraph, via email) on the session.
- This is used in an Area Report as presented in the
- Proceedings of each IETF meeting.
-
- Distribute the work
-
- Of course each WG will have participants who may not be able
- (or want) to do any work at all. Most of the time the bulk
- of the work is done by a few dedicated participants. It is
- the task of the Chair to motivate enough experts to allow
- for a fair distribution of the workload.
-
- Document development
-
- Working groups produce documents and documents need authors.
- The Chair will make sure that authors of WG documents
- incorporate changes as discussed by the WG. See the section
- on Session Documents for details procedures.
-
-
-
-
-
- Huizer & Crocker [Page 18]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
- Document publication
-
- The Chair and/or Secretary will work with the RFC Editor to
- ensure document conformance with RFC publication
- requirements and to coordinate any editorial changes
- suggested by the RFC Editor. A particular concern is that
- all participants are working from the same version of a
- document at the same time.
-
- 5.2. WG Editor/Secretary
-
- Taking minutes and editing working group documents often is performed
- by a specifically-designated participant or set of participants. In
- this role, the Editor's job is to record WG decisions, rather than to
- perform basic specification.
-
- 5.3. WG Facilitator
-
- When meetings tend to become distracted or divisive, it often is
- helpful to assign the task of "process management" to one
- participant. Their job is to oversee the nature, rather than the
- content, of participant interactions. That is, they attend to the
- style of the discussion and to the schedule of the agenda, rather
- than making direct technical contributions themselves.
-
- 5.4. Design teams
-
- The majority of the detailed specification effort within a working
- group may be done by self-selecting sub-groups, called design teams,
- with the (implicit or explicit) approval of the working group. The
- team may hold closed sessions for conducting portions of the
- specification effort. In some cases design teams are necessary to
- make forward progress when preparing a document. All work conducted
- by a design team must be available for review by all working group
- participants and the design team must be responsive to the direction
- of the working group's consensus.
-
- 5.5. Area Consultant
-
- At the discretion of the AD, a Consultant may be assigned to a
- working group. Consultants are senior participants in the IETF
- community. They have technical background appropriate to the WG and
- experience in Internet architecture and IETF process.
-
-
-
-
-
-
-
-
- Huizer & Crocker [Page 19]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
- 5.6. Area Director
-
- Area Directors are responsible for ensuring that working groups in
- their area produce coherent, coordinated, architecturally consistent
- and timely output as a contribution to the overall results of the
- IETF. This very general description encompasses at the very least
- these detailed tasks related to working groups:
-
- Area planning
-
- The Area Director determines activities appropriate to the
- area. This may include initiating working groups directly,
- rather than waiting for proposals from IETF participants.
-
- Coordination of WGs
-
- The Area Director coordinates the work done by the various
- WGs within (and sometimes even outside) the relevant area.
-
- IETF Meeting Schedule
-
- The Director tries to coordinate sessions in such a way that
- experts can attend the relevant sessions with a minimum of
- overlap and gaps between sessions. (See section on WG
- sessions for details.)
-
- Reporting
-
- The Area Director reports to the IETF on progress in the
- area.
-
- Reviewing
-
- The Area Director may appoint independent reviewers prior to
- document approval. The Area Director tracks the progress of
- documents from the area through the IESG review process, and
- report back on this to the WG Chair(s).
-
- Progress tracking
-
- The Area Director tracks and manages the progress of the
- various WGs with the aid of a regular status report on
- documents and milestones that is generated by the IESG
- Secretary. The Area Director forwards this report to the WG
- chairs. This in turn helps the chairs to manage their WGs.
-
-
-
-
-
-
- Huizer & Crocker [Page 20]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
- 5.7. Area Directorate
-
- An area directorate consists of senior members of the technical
- community and are appointed by the Area Director who then tasks them
- with technical oversight and review of specific area activities. An
- Area Director chairs the directorate. At the request of the AD,
- directorate members conduct specification reviews and may be assigned
- as Area Consultants, to provide architectural assistance.
-
- 6. WORKING GROUP DOCUMENTS
-
- 6.1. Session documents
-
- All relevant documents for a session (including the final agenda)
- should be published and available at least two weeks before a session
- starts.
-
- It is strongly suggested that the WG Chair make sure that an
- anonymous FTP directory be available for the upcoming session. All
- relevant documents (including the final agenda and the minutes of the
- last session) should be placed in this directory. This has the
- advantage that all participants can FTP all files in this directory
- and thus make sure they have all relevant documents. Also, it will be
- helpful to provide electronic mail-based retrieval for those
- documents.
-
- 6.2. IETF meeting document archive
-
- In preparing for an IETF meeting it is helpful to have ready access
- to all documents that are being reviewed. While documents usually are
- placed in the internet-drafts Internet Repository or in the
- respective working group archives or just published in some mail-
- lists, there are just too many things to browse or read through.
- Also, many documents are modified immediately before a meeting.
-
- The InterNIC Directory and Database Services provides a current-
- ietf-docs archive to enable people to get all documents that are
- relevant for the up-coming IETF meeting. This document database will
- be removed two weeks after the IETF meeting.
-
- The completeness of this archive depends on the authors and working
- group chairs submitting the documents. Each WG Chair is requested to
- submit the agenda to this archive.
-
- Structure of the archive:
-
- On ds.internic.net documents will be stored under the appropriate
- working group name under the appropriate area name in the directory:
-
-
-
- Huizer & Crocker [Page 21]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
- /pub/current-ietf-docs
-
- Each area will also have a directory called bof where a document to
- be discussed in a BOF meeting will be placed. At the area level a
- directory called plenary will be created to hold documents or
- presentation material related to a plenary session. Any filename
- conflicts will be resolved by the InterNIC's administrator and the
- submitter will be informed via electronic mail. Example:
-
- /pub/current-ietf-docs/app/osids
- /pub/current-ietf-docs/int/sip
-
- Access via anonymous FTP:
-
- Anonymous FTP to ds.internic.net and change directory to
-
- /pub/current-ietf-docs/
-
- and browse and get the document of interest.
-
- Access via gopher:
-
- Connect to gopher.internic.net and select the menu item:
-
- 4. InterNIC Directory and Database Services (AT&T)/
-
- and then the menu item:
-
- 3. Documents to be reviewed at the *** IETF
-
- One may use the public-access gopher client by:
-
- telnet gopher.internic.net
-
- Submission of documents via anonymous FTP:
-
- FTP to ds.internic.net and login as anonymous. Change directory to:
-
- /incoming/current-ietf-docs
-
- Put the document using the following filename convention,
-
- <area>.<wgname>.<filename>
- e.g.:
-
- plenary.mondayVGs.ps
- app.osids.agenda
- app.osids.internic-talk-VGs.ps
-
-
-
- Huizer & Crocker [Page 22]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
- Note that the names of areas and working groups are their official
- short-form acronyms,
-
- Submission of documents via electronic mail:
-
- Send mail to
-
- admin@ds.internic.net
-
- with the following subject line:
-
- IETF - <area>.<wgname>.<filename>
-
- e.g.:
-
- IETF - app.osids.agenda
-
- NOTE: Instead of sending a fresh copy of an already available
- document, you may ask the InterNIC's administrators to create a link
- to an existing internet-draft/RFC/ID
-
- NOTE: If you do not remember your area or working group acronym get
- the file /ftp/ietf/1wg-summary.txt from ds.internic.net via anonymous
- FTP.
-
- 6.3. Internet-Drafts (I-D)
-
- The Internet-Drafts directory is provided to working groups as a
- resource for posting and disseminating early copies of working group
- documents. This repository is replicated at various locations around
- the Internet. It is encouraged that draft documents be posted as soon
- as they become reasonably stable.
-
- It is stressed here that Internet-Drafts are working documents and
- have no official standards status whatsoever. They may, eventually,
- turn into a standards-track document or they may sink from sight.
- Internet-Drafts are submitted to:
-
- internet-drafts@cnri.reston.va.us
-
- The format of an Internet-Draft must be the same as for an RFC [2].
- Further, an I-D must contain:
-
- - Beginning, standard, boilerplate text which is provided by
- the Secretariat;
-
- - The I-D filename; and
-
-
-
-
- Huizer & Crocker [Page 23]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
- - The expiration date for the I-D.
-
- Complete specification of requirements for an Internet-Draft are
- found in the file:
-
- 1id-guidelines.txt
-
- in the internet-drafts directory at an Internet Repository site.
-
- 6.4. Request For Comments (RFC)
-
- The work of an IETF working group usually results in publication of
- one or more documents, as part of the Request For Comments (RFCs) [2]
- series. This series is the archival publication record for the
- Internet community. A document can be written by an individual in a
- working group, by a group as a whole with a designated Editor, or by
- others not involved with the IETF. The designated author need not be
- the group Chair(s).
-
- NOTE: The RFC series is a publication mechanism only and publication
- does not determine the IETF status of a document. Status is
- determined through separate, explicit status labels assigned by the
- IESG on behalf of the IETF. In other words, the reader is reminded
- that all Internet Standards are published as RFCs, but NOT all RFCs
- specify standards.
-
- For a description on the various categories of RFCs the reader is
- referred to [1, 4, 5, 6].
-
- 6.5. Submission of documents
-
- When a WG decides that a document is ready for publication, the
- following must be done:
-
- - The version of the relevant document as approved by the WG
- must be in the Internet-Drafts directory;
-
- - The relevant document must be formatted according to RFC
- rules [2].
-
- - The WG Chair sends email to the relevant Area Director, with
- a copy to the IESG Secretary. The mail should contain the
- reference to the document, and the request that it be
- progressed as an Informational, Experimental, Prototype or
- standards-track (Proposed, Draft or Internet Standard) RFC.
-
- The IESG Secretary will acknowledge receipt of the email. Unless
- returned to the WG for further development, progressing of the
-
-
-
- Huizer & Crocker [Page 24]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
- document is then the responsibility of the IESG. After IESG
- approval, responsibility for final disposition is the joint
- responsibility of the RFC Editor and the WG Chair and Editor.
-
- 6.6. Review of documents
-
- Usually in case of a submission intended as an Informational or
- Experimental RFC minimal review is necessary. However, if the WG or
- the RFC Editor thinks that an extensive review is appropriate, the
- Area Director may be asked to conduct one. This review may either be
- done by the AD and other IESG participants or the IESG may ask for an
- independent review (e.g., by someone not part of the WG in question)
- from the Area Directorate or elsewhere.
-
- A review will lead to one of three possible conclusions:
-
- 1. The document is accepted as is.
-
- This fact will be announced by the IESG Secretary to the
- IETF mailing list and to the RFC Editor. Publication is then
- further handled between the RFC Editor and the author(s).
-
- 2. Changes regarding content are suggested to the author(s)/WG.
-
- Suggestions must be clear and direct, so as to facilitate
- working group and author correction of the specification.
- Once the author(s)/WG have made these changes or have
- explained to the satisfaction of the reviewers why the
- changes are not necessary, the document will be accepted for
- publication as under point 1, above.
-
- 3. The document is rejected.
-
- This will need strong and thorough arguments from the
- reviewers. The whole IETF and working group process is
- structured such that this alternative is not likely to arise
- for documents coming from a working group. After all, the
- intentions of the document will already have been described
- in the WG charter, and reviewed at the start of the WG.
-
- If any individual or group of individuals feels that the review
- treatment has been unfair, there is the opportunity to make a
- procedural complaint. The mechanism for procedural complaints is
- described in the section on Contention and Appeal.
-
- Before the IESG makes a final decision on a standards-track document,
- the IESG Secretary will issue a "Last Call" to the IETF mailing list.
- This Last Call will announce the intention of the IESG to consider
-
-
-
- Huizer & Crocker [Page 25]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
- the document, and it will solicit final comments from the IETF within
- a period of two weeks. It is important to note that a Last Call is
- intended as a brief, final check with the Internet community, to make
- sure that no important concerns have been missed or misunderstood.
- The Last Call cannot serve as a more general, in-depth review.
-
- 7. SECURITY CONSIDERATIONS
-
- Security issues are not discussed in this memo.
-
- 8. REFERENCES
-
- [1] Internet Architecture Board and Internet Engineering Steering
- Group, "The Internet Standards Process -- Revision 2", RFC 1602,
- IAB, IESG, March 1994.
-
- [2] Postel, J., "Instructions to RFC Authors", RFC 1543,
- USC/Information Sciences Institute, October 1993.
-
- [3] Malkin, G., and J. Reynolds, "F.Y.I. on F.Y.I. - Introduction to
- the F.Y.I. Notes", RFC 1150, Proteon, USC/Information Sciences
- Institute, March 1990.
-
- [4] Postel, J., Editor, "Introduction to the STD Notes", RFC 1311,
- USC/Information Sciences Institute, March 1992.
-
- [5] Postel, J., Editor, "Internet Official Protocol Standards", STD
- 1, RFC 1600, IAB, March 1994.
-
- [6] Cerf, V., "The Internet Activities Board", RFC 1160, NRI, May
- 1990.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Huizer & Crocker [Page 26]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
- 9. AUTHORS' ADDRESSES
-
- Erik Huizer
- SURFnet bv
- P.O. Box 19035
- 3501 DA Utrecht
- The Netherlands
-
- Phone: +31 30 310290
- Fax: +31 30 340903
- EMail: Erik.Huizer@SURFnet.nl
-
-
- Dave Crocker
- Silicon Graphics, Inc.
- 2011 N. Shoreline Blvd.
- P.O. Box 7311
- Mountain View, CA 94039
-
- Phone: +1 415 390 1804
- Fax: +1 415 962 8404
- EMail: dcrocker@sgi.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Huizer & Crocker [Page 27]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
- APPENDIX: SAMPLE WORKING GROUP CHARTER
-
- Multiparty Multimedia Session Control (mmusic)
-
- Charter
-
- Chair(s):
- Eve Schooler <schooler@isi.edu>
- Abel Weinrib <abel@bellcore.com>
-
- Transport Area Director(s)
- Allison Mankin <mankin@cmf.nrl.navy.mil>
-
- Mailing lists:
- General Discussion:confctrl@isi.edu
- To Subscribe: confctrl-request@isi.edu
- Archive: venera.isi.edu:~/confctrl/confcrtl.mail
-
- Description of Working Group:
-
- The demand for Internet teleconferencing has arrived, yet an
- infrastructure to support this demand is barely in place.
- Multimedia session control, defined as the management and
- coordination of multiple sessions and their multiple users in
- multiple media (e.g., audio, video), is one component of the
- infrastructure. The Multiparty Multimedia Session Control
- Working Group is chartered to design and specify a protocol to
- perform these functions.
-
- The protocol will provide negotiation for session membership,
- underlying communication topology and media configuration. In
- particular, the protocol will support a user initiating a
- multimedia multiparty session with other users ("calling" other
- users) over the Internet by allowing a teleconferencing
- application on one workstation to explicitly rendezvous with
- teleconferencing applications running on remote workstations.
- Defining a standard protocol will enable session-level
- interoperability between different teleconferencing
- implementations.
-
- The focus of the working group is to design a session negotiation
- protocol that is tailored to support tightly-controlled
- conferences. The MBONE currently carries primarily loosely-
- controlled sessions, i.e., sessions with little to no interaction
- among members and with no arbitration facility, security, or
- coordination of quality-of-service options for time-critical
- media. Users may learn of available sessions using the "sd"
- utility or other out of band mechanisms (e.g., email). However,
-
-
-
- Huizer & Crocker [Page 28]
-
- RFC 1603 IETF Working Group Guidelines March 1994
-
-
- there is clearly also a need for tightly-controlled sessions that
- provide mechanisms for directly contacting other users to
- initiate a session and for negotiating conference parameters such
- as membership, media encodings and encryption keys. In addition,
- these sessions should support renegotiation during a session, for
- example to add or delete members or change the media encoding.
- It is possible that the protocol will, in the limiting case, also
- support loosely-controlled sessions.
-
- The main goal of the working group will be to specify the session
- control protocol for use within teleconferencing software over
- the Internet. The working group will focus on the aspects of the
- session control problem that are well understood, while keeping
- an eye on evolving research issues. Toward this end, the working
- group has made an inventory of existing conferencing systems and
- their session control protocols. The working group will document
- the requirements of the existing prototypes as a basis for the
- protocol development. The working group will iteratively refine
- the protocol based on implementation and operational experience.
-
- Furthermore, the working group will coordinate with other efforts
- related to multimedia conferencing, such as directory services
- for cataloguing users and conferences, the RTP and RTCP protocols
- developed by the Audio/Video Transport Working Group, resource
- reservation and management at the network level, and schemes for
- multicast address allocation.
-
- Goals and Milestones:
-
- May 93 Hold an on-line working group meeting to discuss
- the conference control framework, the relevant
- terminology, a functional taxonomy and how
- different conversational styles place
- requirements on session protocols.
-
- Jun 93 Submit the Conference Session Control Protocol to
- the IESG for consideration as an Experimental
- Protocol.
-
- Aug 93 Post an Internet-Draft describing the Session
- Control Requirements.
-
- Nov 93 Post an Internet-Draft of the Session Control
- Protocol.
-
- Mar 94 Submit a revised Internet-Draft based on
- implementation experience.
-
-
-
-
- Huizer & Crocker [Page 29]
-
-